home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
rbbs_pc
/
gm313exe.zip
/
GMON.DOC
< prev
next >
Wrap
Text File
|
1989-09-23
|
44KB
|
1,053 lines
**********************************************
****** Game Monitor (GMon) 3.13 ******
****** By John Morris ******
****** The Reno RBBS-PC ******
****** (702) 746-1358 Voice ******
****** (702) 746-1364 Data 1 8:919/1 ******
****** (702) 746-1365 Data 2 8:919/2 ******
**********************************************
Welcome to GMon. I conceived GMon well over two years ago, and have finally
gotten the program to work like I had originally planned. I wanted a flexible,
yet small and fast Game Monitor for my RBBS. I had originally planned on the
program on being around 70-80k, and it ended up being 85k with all the features
added in. (I was close!). GMon is actually a SINGLE monitor program, but for
compatibility sake it needs a program called MONITOR1.EXE to run Doorware. Thus
my MONITOR1.EXE simply has one function; to 'RUN' GMon. GMon started out as a
central program to run my games from, but it has ended up as a 'Door Control'
program allowing you to run nearly any kind of program through it.
Features of GMon:
-----------------
1. Speed. GMon doesn't have a lot of unnecessary I/O to the user, so they
can get to where they want to go, the games.
2. Size. GMon is a single program, 85k in size. To be compatible with
Doorware, a small program called MONITOR1.EXE is supplied. If you are
writing your own Door programs, you may simply bypass MONITOR1.EXE and
'RUN' GMON.EXE directly. (This also speeds up Door execution.)
3. Maintenance. GMon does its own daily maintenance which will delete
inactive users from your user file. The keeps your NAMES.DOR file
from becoming a creeping terror, taking up more, and more disk space.
You set the maximum amount of days a user may be idle.
4. Paths. GMon can be run a variety of ways. For instance, you could
put GMon in your BBS subdirectory, and put all your other games in
a separate subdirectory, and GMon will function normally. Or, you could
put your BBS in one subdirectory, GMon in another, and the games in yet
another subdirectory. Another method is to put each game in its own
subdirectory. this will allow you to run any version of that game as
long as the files it needs are in the same directory.Or simply put the
BBS, GMon, and the games in the same directory.
5. Color. GMon uses Ansi Color for all prompts. You can tell GMon
to display color ALL the time.
6. Help. GMon has a small help file which the user can display at
anytime.
7. Commands. All commands in GMon are input at the same prompt. Some
commands are similar to RBBS (so as not to confuse the user) such as
the G)oodbye or H)elp commands.
8. Time limits. GMon sets daily time limits, and session limits per user
security level in the RBBS. Also you can specify the time, during the
day, when the user can use GMon.
9. Scoring. When viewing the scores, you get an up-to-the second report of
the current scores.
10. Running a program. To run a program, a user simply needs to input the
number at the same prompt where every other command is given. You DO
NOT need to hit M to run a game. If you wish to see a short listing
of games available, simply hit [ENTER]. And to see a full description
of the games, hit M then Y)es for game descriptions. After the games
are displayed you are back at the same prompt as before. Again, a user
who frequents your games area doesn't have to sit back and have lunch
while the games are displayed everytime, he will get to those games he
wants to play.
11. Each game now has its own security level. You need to edit you GAMES.DOR
file to add this feature, but it is well worth the effort.
12: PCB Doors. GMon has the built-in ability to run PCBoard doors. This
feature will be discussed later.
13: Log. GMon produces its own log show which games are run and by whom.
It also shows when maintenance was run. Etc.
14: GMEdit31. GMon Edit 3.1 is a complete GMon editing program, which can
be used to edit GMon files both from local, AND remote. Files that
can be edited are GMON.DEF, GAMES.DOR, and NAMES.DOR.
Copyright & License Info
------------------------
GMon is Copyrighted by myself (John Morris). This means that I am the
-owner- of GMon. This means that my rights to the program are protected
under National Law, and International Treaty!
Most people shouldn't be concerned with all of that. But there are a
few who insist on tweaking my old code aorund and putting their own
name on it. That practice is Unlawful, Unethical, and just plain theft.
All users of GMon are granted a limited license to use, copy and
distribute GMon any way they see fit as long as a few rules are
obeyed:
1. You may use the program for any commercial, or non-commercial purpose.
Use it on your company, private or school BBS, or just about anything
else, I leave it up to your imagination.
2. You may copy and distribute as many copies of this program as you like,
as long as you don't charge money for the program itself. A small fee
is allowed (for copying, handling, mailing, and the diskette carrying
the copy) is allowed, BUT this amount is not to exceed the real costs.
(in other words, you may NOT make a profit!)
3. The program is used, and/or distributed unmodified, wih complete
documentation.
Warranty
--------
Warranty?? Are you nuts? There is no warranty of ANY kind given on
the operation of GMon! This program is provided AS IS!, and you use it
at your own risk!
GMon Version History
--------------------
1/10/88 - GMon 1.0
-------
First Release of GMon. Written to completely compatible with the Door
Monitor program, with improvements in speed and size.
1/24/88 - GMon 2.0
-------
Release date of version 2 of GMon. The GAMES.DOR file format was completely
reworked to be more flexible. ie: Instead of having to include certain
strings (ex. PCB11) in the descriptions to run PCB doors, you instead just
change the program 'type'. The batch file used by GMon was changed from
GMONPCB.BAT to GMONEXTx.BAT. This was changed to make sure multi-node
systems used the correct batch file. The user interface was changed to
look more like an RBBS command prompt, thus making the user feel at home
with the program (I hope!) You can now customize the menu of commands the
user sees, MENU.MON. An X-pert toggle was added to switch the menu on/off.
2/28/88 - GMon 2.1
-------
GMon 2.1 release date. Several bugs cleared up, and some more info
on batch files was added to the documentation. It should now run as easy
on a single node system as a multi-node system.
3/13/88 - GMon 2.2
-------
GMon 2.2 release date. Fixes were applied to the PCBoard interface which
includes a total rewrite of the PCBOARD.DAT files GMon outputs. This seems
to clear up the 'error 62 at line 10040' problem with PCB12 doors. Also
PCB mode 4 was included which will write out plain PCBOARD.SYS and
PCBOARD.DAT files. Hopefully this will make GMon compatible with other
PCB12 games.. let me know if you find any. SysOps, If you hit the 'F1'
key the program will IMMEDIATELY exit to DOS. I put it in there 'just in
case'.
04/10/88 - GMon 2.3
--------
Gmon 2.3 release date. The PCBoard interface was rewritten (again!) so that
GMon would output a dummy pcboard user file along with the other PCB files
so that all Dorpatch routines greater than 2.6 would run. These fixes work
automatically, so you need to do nothing except add the games to the file
GAMES.DOR and they should run. A bug in the program which didn't write the
exact amount of time used, by the user, was cleared up.
Also added was an improved GMon edit program call GMEDIT20. It includes a
NAMES.DOR editor in addition to the older GMONEDIT functions.
02/15/88 - GMon 3.10 (3.0x released only as a beta test)
--------
GMon 3.0 release date. Several new features added this time. Main feature?
Hmm.. howsabout 15k smaller EXE file.. thats the main feature! Added to
the game are several switches. You can tell GMon to use a different
GAMES.DOR file for each node. This filename would then be GAMESx.DOR
(where x is the node number). You can shorten the GMon prompt to simply:
GMON Command? (without the '<A,B,C,...>' etc). You can have GMon list
games by category. Aliases are now supported by GMon. If you have these
features turned OFF, GMon will look, and behave just exactly like it
did in the past. GMon also now has a batch mode so it can be used as a
simple RBBS - 2 - PCB11/PCB12/PCB14/GAP/WILDCAT! converter. (see below)
GMEdit30 has been rewritten to be used locally, or from remote! Added
to GMEdit30 is a GAMES.DOR editor. GMEdit30 can be accessed by using
the SysOp command of 'E' (for Editor). Be sure GMEDIT30.EXE is in the
same directory as GMON!. When editing the GAMES.DOR file with GMEdit30
you'll notice that GMEdit30 will change the 'look' of the file ever
so slightly. This change in looks doesn't change the way the file works,
so don't worry about it.
02/25/89 - GMon 3.11
--------
A maintenance update to fix a problem in the /C3 and /C4 modes. You'll
no longer get an 'Illegal Function Call' when using these two modes.
09/24/89 - GMon 3.13
--------
Another maintenance update, along with a couple added interfaces. GMon
should now enforce time limts correctly in all cases. Formerly, an entry
in the TIMELIMIT.DOR file that looked like this:
9,45,90,,
would give an error "You must call between 0000 and 2359"
This error is fixed. Also a user could cheat GMon for extra time. This is
also fixed.
The GAP interface is fixed. Added interfaces are and OPENDOOR.SYS (Fast
Fingers door program interface) and a USERINFO.TXT interface (MG Generic
format) For games like Planet Busters.
Also **NEW** batch file info. Some -external- door programs tend to -eat-
command line parameters. So if you run a multi-line system this causes
ALL kinds of problems! I gotta fix! see the batch file section.
MONITOR1.EXE is now written in 'C' which really saves on hard disk space.
Its now an 11k program instead of 28k. Every little bit helps! Look for
GMon to be converted to 'C' in the near future. (along with TW!)
OH YEAH!... Almost forgot. I did some work on GMEdit30.. and fixed that
really nasty GAMES.DOR editor error. Its now known as GMEdit31.
I wish to thank Mike Hammer, and Roger Reesor and everyone else who helped
with their ideas and bug fixes, you have all helped in making GMon the best
it can be. I'd like to be able to name you all, but there are just way
to many of you. GMon wouldn't be possible without you.
Bug Reports / Suggestions / Ideas
---------------------------------
If you can't reach me through my BBS numbers, give me a buzz voice, or
send me mail at:
John Morris
2620 Emily St.
Reno, Nv 89503
I try to be as receptive to ideas as possible, so let me know of your
ideas or suggestions.
Compatibility:
--------------
GMon was first designed to be as compatible as possible with the original
Doorware programs distributed by Bob Westcott. As the program was developed
it was necessary to change some of the file formats around to make GMon
more powerful. If you are running the Doorware Monitor and are thinking of
making the switch to GMon read on.
Changes from the Doorware Monitor program
-----------------------------------------
The Doorware Monitor uses a file called GAMES.DOR to describe the programs
the user can run. It simply contained the program name and a description.
To allow GMon to have total flexibility the GAMES.DOR file was completely
changed. Each line has several parameters.
GAMES.DOR
---------
Here is what a single line from your GAMES.DOR file looks like:
TW2,C:\DOORS\,5,0,Tradewars.. the latest! the greatest! TW2 release 6!
or,
GameName,GameDirectory,GameSecurity,GameType,GameDescription
GMon will parse the line out and reassemble it in memory to look like the
Doorware line, without all the extra info. The Game Name, Directory in,
Security level, and Description are self explanitory. The Game Type is very
easy to understand. GMon knows six (6) game types as follows:
Game Types:
-----------
0 - Regular RBBS door, GMon will use the internal basic RUN command
1 - External Door, Any door to be used without the Run command
2 - PCBoard 11.x door program
3 - PCBoard 12.x door program (PCBOARDx.SYS & DAT is written)
4 - PCBoard 12.x door program (plain PCBOARD.SYS & .DAT w/o node #)
5 - Wildcat door program (using CALLINFO.BBS file)
6 - GAP program (using DOOR.SYS file)
7 - PCBoard 14.x door program (PCBOARDx.SYS is written)
8 - PCBoard 14.x door program (plain PCBOARD.SYS & .DAT are written)
9 - Fast Fingers door program (OPENDOOR.SYS file)
10- MG Generic Format (USERINFO.TXT)
(More MODES coming soon!)
Listing Games By Category!
--------------------------
With the start of GMon 3.0 a SysOp my allow a user to list games by
category. First, You must turn on the 'list programs by category switch'
in GMEDIT30. Then you must make a GAMES.CAT file. It should be formatted
like so:
Adventures
Multi-Player Games
Casino games
Etc.
Each line is a category, so Adventures would be category 1, Casino games
would be category 3, etc.
You should also take note of the special format of the GAMES.DOR file when
specifying category mode. It looks like this:
TW2,C:\DOORS\,5,0,2,Tradewars.. the latest! the greatest! TW2 release 6!
or,
GameName,GameDirectory,GameSecurity,GameType,GameCategory,GameDescription
^ *NEW*
NOTE! there is an added field here! When using category mode, you must
add a new field which is the games category. In the TW2 example above,
the category is 2, and combined with the above GAMES.CAT file, TW2 will
be listed under 'Multi-player games'.
When a user lists the files, he/she will be asked for a category or
'A' for all, when they pick A)ll the games will be listed like normal.
Otherwise, GMon will search for games with the specified category
number.
GAMES.DOR filenames:
--------------------
Beginning with GMon 3.0 you will have 3 options of telling GMon
the FILENAME of the GAMES.DOR file. For Most SysOps all options will
be 'off' and GMon will look for the filename GAMES.DOR.
Some SysOps have special situations that require options. If you wish,
you can tell GMon to use separate GAMES.DOR files for each node. The
filename format will be: GAMESx.DOR where 'x' is the node number.
(make sure if you use this option to have a separate file for each node!)
A third option allows you to override the regular GMon conventions
and specify the GAMES.DOR file on the command line. To use this option
use the command line switch: /O filename.ext
Example: GMON 1 /O GMONBETA.DOR
Gmon will load and look for game descriptions in the GMONBETA.DOR file.
NOTE: The internal format of the file doesn't change, just the filename.
Game Types (again):
-------------------
Doorware programs will be run with the Type '0', the others are for special
programs. The PCBoard modes are the same as the external mode, but GMon
will also write the correct PCBoard files in the sub-directory you indicate.
Game Security:
--------------
If a users security level is below the game security level, then the game will
be TOTALLY invisible to the user. A good way to use security levels to your
advantage is like this; You could actually add TWEDIT to you GAMES.DOR file
but assign it a security level high enough so only you or a remote sysop could
enter it, and edit your Tradewars data file.
Game Subdirectories:
--------------------
NOTE!:
Because you now specify a sub-directory for EVERY game, you must make sure
the RBBSxPC.DEF is located in every sub-directory in which you have placed
an RBBS door (Of course, this is ONLY if the game requires it!, and nowadays
not too many games use the .DEF file).
GAMES.DOR formats:
------------------
You CANNOT have any commas OR double quotes in the game description OR GMon
will NOT load properly! This can cause many mysterious errors!
The format of the GAMES.DOR file must be exactly as stated, so look through
the games.dor file provided to compare it with yours in case you have a
problem. If your format isn't correct you WILL have problems, so beware!
TIMLIMIT.DOR
------------
The new TIMLIMIT.DOR file will assign session and daily limits per security
level. You can also specify what time of day a user can use GMon.
A sample of my TIMLIMIT.DOR file:
format: Security level,Session limit,Daily limit,Start Time,End Time
5,25,45,0600,1600
6,30,60,0400,2000
7,45,75,,
20,90,180,,
It is easy to see how it works. Line one would allow a user at level 5 a
session limit of 25 minutes, and a daily limit of 45 minutes, and they
could use GMon between 6am and 4pm. Line 4 would allow a level 20 user a
session limit of 90 minutes, and a daily limit of 180 minutes, and there
is no restriction as to when they can use the monitor.
SCORBRD1.DOR
------------
This file is the same as the Doorware Monitor MONITOR1.SCR file.
MONITOR.SCR can be erased (if you are using the doorware monitor)
GMON.DEF and GMEDIT30.EXE
-------------------------
GMon stores all its necessary info in a file called GMON.DEF To create
GMON.DEF just run the included program GMEDIT30 and if no GMON.DEF is
found a new one will be created. First you will be displayed what the
current GMon defaults are, and you can edit them to your tastes. Because
I wish to keep GMon as flexible as possible, it was suggested that I
do NOT rely upon the RBBSxPC.DEF file for my info. This will let you
continue running GMon after you switch to another version of RBBS which
has a different RBBSxPC.DEF file. GMon keeps all its needed info in the
GMON.DEF file.
Record 1 Field 1 this is the name of your messages file (usually MESSAGES)
withOUT the drive or path
Record 1 field 3 SubDir where the BBS files are located, most notably,
the MESSAGES file, and the DORINFOx.DEF file.
The rest of the fields in record one are self explanitory.
The other records are the 'NODE' records.
VERY IMPORTANT! : Be sure to edit your node records, and input the correct
RCTTY.BAT filename in field one. Failure to do so will
cause some wierd errors.
NOTE: Because GMon constantly changes the node record information I think it
would be best to edit just the RCTTY.BAT field info. But I do provide
a means to edit all other node record fields.
Old Doorware under GMon:
------------------------
Because of the way older Doorware worked, the RCTTY.BAT filename was needed
so they can be run in a separate directory, GMon will copy the bat file
over to the directory where the game is. If you happen to keep getting the:
'TO RUN IN LOCAL MODE READ SYSOP.DOC' message, then you are probably missing
the bat file. My door games determine local/remote modes by checking if
there is a carrier or not, so this problem is avoided.
Signing on in LOCAL mode
------------------------
Because of the size and speed constraints I placed on GMON, you may either
sign on to GMON locally through an RBBS node that is configured specifically
for COM0 in the CONFIG program that comes with RBBS, or you must enter your
BBS locally using the ESC key, log off your BBS, hit the F1 key to leave
RBBS, and then run GMon (or the GMon .BAT file).
If you use the COM0 method you logon to RBBS using your sysop passwords as
specified in CONFIG, then go to the doors section and select the games.
RBBS will exit to the GMON batch file and run GMON in local mode so you can
test the games and see how your logic works in the batch files you write.
This is especially useful in writing PCBoard batch files, as described
below. You still need to run Doorware-type games in the manner explained
in the Doorware docs, and then you can reinistate GMON by running the GMON
batch file (GAMES.BAT in these illustrations).
(**NOTE!**: GMEDIT30 will run from DOS with this command only> GMEDIT30 /L)
Files GMON creates for it's own use
-----------------------------------
These files are created and maintained entirely by the GMON program for it's
own use, so if you see them listed when you do a directory of your RBBS and
games areas do not be alarmed or worry about these files' purpose.
FILENAME PURPOSE IN GMON
~~~~~~~~ ~~~~~~~~~~~~~~~
NAMES.DOR Keeps track of all users who sign on through GMON.
TIMEOFFx.DOR Holds seven fields of info that RBBS doorware and
the MONITOR1.EXE program needs. 'x' - stands for
the node number, and is '0' on a single node system.
MONILOG.DOR Callers file for GMON. Keeps track of user activities
through GMON.
PCBOARDx.SYS These three files hold info needed by PCBoard doors to
PCBOARDx.DAT operate properly.
GMUSERS.DAT
ERRORS.DOR Holds a record of all errors encountered by the GMON
program in it's operation -- a "must read" if you
are having problems. Most common error encountered
by GMon testers - a file needed was not in the proper
subdirectory. Check which files you have where, and
if necessary copy all data files to all places to make
the problem go away.
GMON.TMP This file MUST contain the directory in which GMon
resides. If not, all sorts of wierd things happen!
Because of GMon's ability to handle so many subdirectories it is easy to
become hopelessly lost in the process unless you follow proper programming
procedures and have a chart of what you are trying to accomplish. A
subdirectory tree is most helpful, as is a logic chart showing you exactly
what you are trying to get your door system to do.
Running RBBS Doorware-type and most other games
-----------------------------------------------
These files are handled very easily through GMON because of the MONITOR1.EXE
program included in the GMON package. Your batch file to run the game needs
to be named exactly as the name of the program appears in the GAMES.DOR file,
so if you have a line that is:
TW2,C:\DOORS\,5,0,Tradewars.. the latest! the greatest! TW2 release 6!
in GAMES.DOR, your filename to execute the TW2 program needs to be TW2.EXE
or TW2.COM and GMON will parse the command through the system to read
TW2 %1
, where the %1 means as usual the node ID number. If you are running no nodes
then the command given out through GMON is, simply,
TW2 '. To end the sentence!
And since Doorware games return to the program MONITOR1.EXE, which runs GMON,
your user will be returned to the GMON program when they are done.
So all you must do to get a regular RBBS door to operate is to list the name
of the file that starts the progran in the GAMES.DOR file as noted in the
GAMES.DOR file description, put all the files for that program in the
subdirectory you indicated in GMON.DEF, and you are all set!
Quirks with Doorware Games:
---------------------------
The Doorware game distributed by Bob Westcott seem to have one annoying
quirk. The games are compatible with RBBS-PC and QBBS, but in the process
of adding compatability to QBBS the games are left with a flaw. For a QBBS
sysop to run a program in LOCAL mode, they must run the program without a
command line, or:
KING
To tell the game a remote user is on a command line parameter must be
specified, or:
KING 1
If you are running a multi-line RBBS you won't into this problem because
there is always a command line (specifying your node number). Single node
systems don't need a command line parameter, so when that user eventually
gets to the Doorware, the game thinks its LOCAL, no matter what! To fix
this problem, you can set up your system as if it was 'Node 1' of a multi
node system. Rename your .DEF file to RBBS1PC.DEF, run RBBS-PC like this:
RBBS-PC 1
and GMon like this:
GMON 1
and the doorware games should run fine from remote.. But here is where the
catch 22 comes in.. they won't run LOCALly this way!
Take a deep breath and relax!
Again, this is very easy to set up and if something is not working right
then sit back, calm down, and think about what you have done. The MONITOR1
program needs to be in all the places where you have games located, and for
this reason it is usually easiest to have all the RBBS Doorware-type games in
one subdirectory.
BATCH FILES!! (read me!) 09/20/89
-----------------------------------
Most of us are not wizards with batch files, though when it comes right
down to it, they are very easy to understand. Below I will construct a
batch file flow chart which explains what happens:
*****NOTE********************************************09/20/89**********
Because some door programs -EAT- the command line parameters,
we will set up the MULTI-NODE batch files differently than before!
First, put this command in your AUTOEXEC.BAT file:
SET NODE=x
Where 'x' is the node number. Thats it for now. Whenever DOS sees a
%NODE% in a batch file, it will substitute the node number (x) instead.
***********************************************************************
RBBS.BAT is invoked -------------
after AUTOEXEC.BAT | RBBS.BAT | (run RBBS) <----<
and runs RBBS-PC. ------------- |
| |
| |
RBBS-PC creates this ------------- (contains the name |
file to run doors, if | RCTTY.BAT | of the Door batch |
RBBS.BAT finds it, it ------------- file to invoke) |
runs it | |
| |
------------- |
>------------> | GAMES.BAT | (run GMon) |
| ------------- |
| | |
| | |
| (see note ---------------- |
| on this | GMONEXTx.BAT | >----------------^
| batch file) ---------------- (no, it doesn't exist, run RBBS.BAT)
| |
| | (yes, it exists, run external door batch file)
| |
| -------------
| | CHESS.BAT | (run CHESS DOOR)
| -------------
| |
| |
^---------------------<
(TOP GUN ends, return to GMon)
GMONEXTx.BAT (GMON.EXE creates this batch file to run
external doors, If GAMES.BAT finds it, it runs
it. Inside this batch is the name of the batch
file used to run the external door program. If
GMONEXTx.BAT does NOT exist, then GAMES.BAT must
change directory to the RBBS directory and end,
this will automatically re-invoke RBBS.BAT)
CHESS.BAT (this batch file is run by GMONEXTx.BAT, when
the user is done with chess, the CHESS.BAT
file MUST change directory back to the RBBS
directory and reinvoke the GAMES.BAT file!)
> Make sure this external batch file is <
> in the same directory as GMon!! <
Example Batch files below:
--------------------------
RBBS.BAT single node system:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
WATCHDG1 OFF 'TURN OFF WATCHDOG PROGRAM FOR COM1
IF EXIST RBBS1F1.DEF DEL RBBS1F1.DEF 'DELETE -F1- FILE CREATED BY RBBS
IF EXIST RCTTY.BAT DEL RCTTY.BAT 'DELETE RCTTY.BAT FILE (IF PRESENT)
RBBS-PC.EXE 'RUN RBBS-PC
IF EXIST RBBS1F1.DEF GOTO EXIT 'IF F1 KEY PRESSED, EXIT BATCH FILE
IF EXIST RCTTY.BAT WATCHDG1 ON 'TURN ON WATCHDOG PROGRAM
IF EXIST RCTTY.BAT RCTTY.BAT 'RUN RCTTY.BAT FILE
CD\ 'RETURN TO RBBS SUBDIR (JUST IN CASE)
RBBS.BAT 'RESTART RBBS.BAT FILE
:EXIT 'BAT FILE GOES HERE IF F1 KEY PRESSED
RBBS.BAT multi-node system: (used for all nodes!)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
WATCHDG1 OFF 'TURN OFF WATCHDOG PROGRAM
IF EXIST RBBS%NODE%F1.DEF DEL RBBS%NODE%F1.DEF 'DELETE F1 FILE CREATE BY RBBS
IF EXIST RCTTY%NODE%.BAT DEL RCTTY%NODE%.BAT 'DELETE RCTTY FILE (IF PRESENT)
RBBS-PC.EXE %NODE% 'RUN RBBS-PC.EXE FOR THIS NODE
IF EXIST RBBS%NODE%F1.DEF GOTO EXIT 'IF F1 KEY PRESSED, EXIT BATCH FILE
IF EXIST RCTTY%NODE%.BAT WATCHDG1 ON 'TURN ON WATCHDOG PROGRAM
IF EXIST RCTTY%NODE%.BAT RCTTY%NODE%.BAT 'RUN RCTTY.BAT FILE
CD\ 'RETURN TO RBBS SUBDIR (JUST IN CASE)
RBBS.BAT 'RESTART RBBS1.BAT FILE
:EXIT 'BAT FILE GOES HERE IF F1 KEY PRESSED
RCTTY.BAT -----> RBBS-PC.EXE CREATES THIS FILE, DON'T WORRY ABOUT IT!
GAMES.BAT single node system:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
WATCHDG1 OFF 'TURN OFF WATCHDOG PROGRAM
IF EXIST GMONEXT1.BAT DEL GMONEXT1.BAT 'DELETE SPECIAL GMON BATCH FILE
GMON.EXE 'RUN GMON
IF EXIST GMONEXT1.BAT GMONEXT1.BAT 'RUN SPECIAL GMON BATCH FILE
CD\ 'RETURN TO RBBS SUBDIR (JUST IN CASE)
GAMES.BAT multi-node system: (same .bat file used by BOTH nodes!)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
WATCHDOG OFF 'TURN OFF WATCHDOG PROGRAM
IF EXIST GMONEXT%NODE%.BAT DEL GMONEXT%NODE%.BAT 'DELETE GMON BATCH FILE
GMON.EXE %NODE% 'RUN GMON
IF EXIST GMONEXT%NODE%.BAT GMONEXT%NODE%.BAT 'RUN GMON BATCH FILE
CD\ 'CD TO RBBS SUBDIR (JUST IN CASE)
GMONEXTx.BAT ----> GMON.EXE CREATES THIS FILE, DON'T WORRY ABOUT IT!
PCBoard door compatability
--------------------------
Because of the lack of readily available conversion program to run PCB
doors from your RBBS, I included the capability in GMon. (There are
a couple conversion programs, but they either aren't cheap, or there is
no source code)
With the Latest release of GMon, there are three (3) ways to tell GMon you
are running a PCBoard door program.
If you wish to use a PCB version 11.x door, you need to set the program
Type to '2'. (see below example)
If you wish to run a PCB version 12.x game, you need to set the program
Type to '3'. (see below example)
To increase the likelyhood of comaptibility, I have made a mode '4' which
will write out plain PCBOARD.SYS, and PCBOARD.DAT files without the node
number. This is for games where you cannot specify the exact SYS file to
look for.. This mode will write PCB 12.x files only.
Version 3.0 adds a new PCBoard mode, 14. If you specify mode 7, or 8, you
will be able to run PCBoard 14 doors as they become available.
I suggest you use PCBoard doors that use Clint Labarthes Door Patch Routines,
or Sam Smiths ProKit. I've tested ProKit (for PCB14) doors with success.
After you have set up the descriptions in the GAMES.DOR file example:
TopGun,C:\DOORS\PCB\,5,2,Top Gun Trivia, Great Trivia Game!
Bull,C:\DOORS\PCB\,5,3,Bay Street Bulls, fun stock market simulation!
Next you need to set up the PCB door programs (the ones using the Door
patch routines) to search for the files PCBOARDx.SYS and PCBOARDx.DAT
(where x is the node) you do this in the .CFG file.
*** NOTE: GMon will write the PCBoard files to the sub-directory specified
Let me show you what I did to get Top Gun trivia working.
My set-up:
The BBS is in C:\RBBS
GMon is in C:\RBBS
The RBBS Doors are in C:\DOORS\
The PCB Doors are in C:\DOORS\PCB\
ALL nodes use COM2
IN a single node system you would simply edit the TGTRIV.CFG. The first
three lines are the main ones. The first line is the com port that you
are using. second is the drive/path to the PCBOARD.SYS file and the third
is the name of your BBS. example:
COM2
PCBOARD1.SYS
The Reno RBBS
Television & Movies
Music
Etc.
Etc.
For Door Patch doors, GMon will create the PCBOARDx.SYS file in the
sub-directory where the door resides. so you need to include a drive/path
in the GAMES.DOR file so the PCB door can locate the .SYS file.
If you are running multiple nodes, you need to copy and rename your .CFG
files. ie: TGTRIV1.CFG TGTRIV2.CFG etc. TGTRIV1.CFG would look like
the example above and TGTRIV2.CFG would look like:
COM2
PCBOARD2.SYS
The Reno RBBS
blah blah
etc.
After you have the .CFG files set-up, you next need to create some batch
files. (see above batch file section)
First AND Most important, create the GAMES.BAT file shown above. If needed,
change its contents to suit your systems set-up.
Next batch file. TOPGUN.BAT
Single node batch file:
~~~~~~~~~~~~~~~~~~~~~~~
CD\DOORS\PCB
TGTRIVIA.EXE TGTRIV.CFG
CD\
GAMES.BAT
Multi-node batch file:
~~~~~~~~~~~~~~~~~~~~~~
CD\DOORS\PCB 'go to PCB door area
TGTRIVIA.EXE TGTRIV%NODE%.CFG 'run Top Gun..look for .CFG file
CD\ 'get back to BBS directory
GAMES.BAT %NODE% 'run gmon batch file again
Here is how it runs.
-------------
| RBBS.BAT | (run RBBS) <----<
------------- |
| |
| |
------------- (created by RBBS to|
| RCTTY.BAT | run doors batch |
------------- files) |
| |
| |
------------- |
>------------> | GAMES.BAT | (run GMon) |
| ------------- | (no, it doesn't
| | | exist, return
| | | to bbs)
| ---------------- |
| | GMONEXTx.BAT | >----------------^
| ----------------
| |
| | (yes, it exists, run it)
| |
| --------------
| | TOPGUN.BAT | (run TOP GUN TRIVIA)
| --------------
| |
| |
^---------------------<
(TOP GUN ends, return to GMon)
When GMon senses a PCB door it creates a batch file which will run a batch
file with the same name as the game, instead of 'RUNning' the game as
happens normally. This batch will run the game, after the game is done, the
batch file must run the GAMES.BAT file again to get to GMon. GMon 'remembers'
that it ran an External/PCB door, and will come on-line just like it would
after running a regular door.
GMon will allow a user at E,7,1 to run a PCB 12 OR 14 door only, 11.x PCB
didn't support those parameters.
NOTE: As you may have noticed, this part of the documentation isn't
very clear. Its really hard to explain the whole thing, and I hope
I included everything. If you have problems, just let me know and I'll
give the PCBoard section a rewrite.
PCBoard (c) 1985...1989 Clark Developement Company, Inc.
Running 'Other' Programs through GMON
--------------------------------------
It is possible to run ANY program through GMON that can output through a
modem by running it as if it were a door program. This is because of
GMON's way of calling the External programs via batch files instead of
calling the external program via it's program name.
The first example of an 'Other' program is to run the Chessdor through
GMon. The Chess program does NOT recognize the Monitor program, so
you'll need to set the program type to '1' to turn on the external
program mode. Like this:
Chess,C:\DOORS\,5,1,Play Chess against other users of this BBS.
^You must make sure you have a CHESS.BAT file in the GMon directory. It
should look like this:
Single node batch file:
~~~~~~~~~~~~~~~~~~~~~~~
CD\DOORS
CHESSDOR
CD\
GAMES.BAT
Multi-node batch file:
~~~~~~~~~~~~~~~~~~~~~~
CD\DOORS 'change sub-dirs to the Chess directory
CHESSDOR %NODE% 'run Chessdor (see above for %NODE% info)
CD\ 'changes sub-dirs to the GMon directory
GAMES.BAT %NODE% 'run the gmon batch file
After you exit the Chess door, you will be returned to GMon, just like
all other doors.
Other ways of using the external program mode:
----------------------------------------------
You can write a batch file that redirects output through the comm port using
the DOS redirection commands and the DOS EXIT function, and this has been
done by the testers of GMON quite successfully. Because of the individual
nature of such programming, all we can do is suggest a format for the batch
file that needs to be written to execute the program. One of ours from
testing is as follows.
Filename: OTHERS.BAT
Listing in GAMES.DOR -
OTHERS,C:\SECRET\,100,1,SYSOP'S MYSTERIOUS OTHER PROGRAM
^ note that 100 is SYSOP access on this tester's system
and that pgm tpye '1' calls batch routine in GMON
CONTENTS OF FILE OTHERS.BAT (that actually is called by GMON)
Single node batch file: (COM1 USED IN EXAMPLE)
~~~~~~~~~~~~~~~~~~~~~~~
WATCHDG1 ON
CD \PGMDIR
MAINTAIN >COM1 <COM1
CD \RBBS
WATCHDG1 OFF
GAMES.BAT
Multi-node batch file: (node 1 = COM1, node 2 = COM2)
~~~~~~~~~~~~~~~~~~~~~~
WATCHDG%1 ON 'sets up carrier detect program for COM%1
CD \PGMDIR 'changes directory to program's directory
MAINTAIN >COM%1 <COM%1 'runs program MAINTAIN (RBBS updating) through COM%1
CD \RBBS 'returns to RBBS directory when done
WATCHDG%1 OFF 'turns off carrier detect program
GAMES.BAT %1 'runs the GMON .BAT file to get GMON up again
Remember that while GMon makes such programming possible, it is entirely up
to you to execute it and because of time constraints I cannot help you
at all in this area!
Misc GMon Stuff
---------------
Running GMon as a simple Converter program:
GMon will run in batch mode so it can create a set of conversion files
then exit back to DOS. To run GMon in this mode you need to use the
'/Cx' switch (where 'x' is the door type.. door types are found above)
If you ran GMon like this from a batch file: GMON 1 /C6
Gmo will create a DOOR.SYS file used by GAP doors, and then exit back to
DOS. Some notes: when using the /Cx switch you must have the node number
first (as in the example) and the node number MUST be there even on a
single node system! On a single node the number would be 1. In this mode
GMon still needs to be run from the BBS in a batch file because it needs
a current DORINFOx.DEF file to convert from RBBS to whatever.
To run GMEDIT30 in local mode (from dos, or the first time you use GMEDIT30)
use the command:
C>GMEDIT30 /L
GMon requires the presence and correct format of the file DORINFOx.DEF
to run properly. No modifications are needed to the file for GMon to
run properly.
If you are running 15-1B or earlier you need to replace the
subroutine DOOREXIT in your version of RBBS with the one included in
GMON151B.MRG. The file is written as a merge against the 15-1B
version of RBBS, but you can also use it with other versions of RBBS
that use those variables, like 15-1A. We have not tested it with
any versions earlier than 15-1A, and remember that other door games
may need the file formats of earlier RBBSs, although no reason comes
to mind. The main purpose of the merge is to make RBBS create
DORINFOx.DEF before it exits RBBS, so feel free to experiment with
the merge and adapt it to your purposes! Keep in mind that GMon and
the RBBS door games may call on files like MESSAGES and USERS to get
information and therefore you may not be able to run GMon or RBBS
door games from PC-Boards and other BBS systems without heavy
modifications or adaptations. If you are not running RBBS, you
are on your own as we do not know enough about other BBSs to be of
much help.
Because you can have the games in a separate subdirectory, you have the
capability of running an older version of your door games AFTER you upgrade
to a new version of RBBS. In my case, I am running NO 151C doors, all are
151B compatible. I put them in a separate subdirectory, and copied over my
151B .DEF files. This keeps GMon flexible, and your BBS flexible. This
way you can take your time in getting the new door games for your new
version of RBBS, or you could avoid that altogether.
As Always, report all Ideas, Bugs, or anything else, I want to here from
ya!
I'm looking for all door program types known to modern man, which I would
like to add to my already large list of door programs in my download
directories. So, if you have some door programs and the money to burn to
upload them, I'd appreciate it very much. By all door program types, I mean
RBBS doors, PCBoard doors, Opus doors....etc.etc.etc. the more the merrier.
Or, you can send them on disk (3 1/2", 720k - 1.44M or 5 1/4", 1.2M), to:
The Reno RBBS
2620 Emily St.
Reno, NV 89503
Registration
------------
GMon is now distributed under the Shareware concept. A contribution
of $35 is suggested if you use and like GMon. This contribution will
help me keep up on my programming expenses and keep newer versions of
GMon coming at a regular rate.
*IF* requested, I will send a copy of GMon's source code after I receive
the contribution.
Formats available for source code disks: 3 1/2" 720K or, 5 1/4" 1.2M
Make Checks Payable to: John Morris
John Morris
The Reno RBBS
3/12/24/9600 HST
702-746-1364 DATA
702-746-1365 DATA
702-746-1358 VOICE